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Abstract 

We propose a light-weight approach for certification 
of monitor inhning for sequential Java bytecode using 
proof-carrying code. The goal is to enable the use 
of monitoring for quality assurance at development 
time, while minimizing the need for post-shipping 
code rewrites as well as changes to the end- host TCB. 
Standard automaton-based security policies express 
constraints on allowed API call/return sequences. 
Proofs are represented as JML-style program anno- 
tations. This is adequate in our case as all proofs 
generated in our framework are recognized in time 
polynomial in the size of the program. Policy adher- 
ence is proved by comparing the transitions of an in- 
lined monitor with those of a trusted "ghost" monitor 
represented using JML-style annotations. At time of 
receiving a program with proof annotations, it is suffi- 
cient for the receiver to plug in its own trusted ghost 
monitor and check the resulting verification condi- 
tions, to verify that inlining has been performed cor- 
rectly, of the correct policy. We have proved correct- 
ness of the approach at the Java bytecode level and 
formalized the proof of soundness in Coq. An imple- 
mentation, including an application loader running 
on a mobile device, is available, and we conclude by 
giving benchmarks for two sample applications. 



1 Introduction 

Program monitoring [23l [20l [8| is a well-established 
technique for software quality assurance, used for a 



wide range of purposes such as performance monitor- 
ing, protocol compliance checking, access control, and 
general security policy enforcement. The conceptual 
model is simple: Monitorable events by a client pro- 
gram are intercepted and routed to a decision point 
where the appropriate action can be taken, depend- 
ing on policy state such as access control lists, or on 
application history. This basic setup can be imple- 
mented in a huge variety of ways. In this paper our 
focus is monitor inlining [15| . In this approach, mon- 
itor functionality is weaved into client code in AOP 
style, with three main benefits: 

• Extensions to the TCB needed for managing ex- 
ecution of the client, intercepting and routing 
events, and policy decision and enforcement are 
to a large extent eliminated. 

• Overhead for marshalling and demarshalling pol- 
icy information between the various decision and 
enforcement points in the system is eliminated. 

• Moreover, there is no need to modify and main- 
tain a custom API or Virtual Machine. 

This, however, presupposes that the user can trust 
that inlining has been performed correctly. This is 
not a problem if the inliner is known to be correct, 
and if inlining is performed within the users juris- 
diction. But it could of interest to make inlining 
available as a quality assurance tool to third parties 
(such as developers or operators) as well. In this pa- 
per we examine if proof-carrying code can be used 
to this effect in the context of Java and mobile ap- 
plications, to enable richer, history-dependent access 
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control than what is ahowed by the current, static 
sandboxing regime. 

Our approach is as follows: We assume that J2ME 
applications are equipped with contracts that ex- 
press the provider commitments on allowed sequences 
of API calls performed by the application. Con- 
tracts are given as security automata in the style of 
Schneider [3D] in a simple contract specification lan- 
guage ConSpec [5]. The contract is compiled into 
bytecode and inlined into the application code as in 
PoET/PSLang [T3], and a proof is generated assert- 
ing that the inlined program adheres to the contract, 
producing in the end a self-certifying code "bundle" 
consisting of the application code, the contract, and 
an embedded proof object. 

Upon reception the remote device first determines 
whether the received bundle should be accepted for 
execution, by comparing the received contract with 
the device policy. This test uses a simulation or lan- 
guage containment test, and is explored in detail by 
K. Naliuka et al. [7|. 

The contribution of this paper is the efficient repre- 
sentation, generation, and checking of proof objects. 
The key idea is to compare the effects of the inlined, 
untrusted, monitor with a "ghost" monitor which im- 
plements the intended contract. A ghost monitor is 
a virtual monitor which is never actually executed, 
and which is represented using program annotations. 
Such a ghost monitor is readily available by simply 
interpreting the statements of the ConSpec contract 
as monitor updates performed before and after se- 
curity relevant method calls. No JVM compilation is 
required at this point, since these updates are present 
solely for proof verification purposes. 

The states of the two monitors are compared stat- 
ically through a monitor invariant, expressing that 
the state of the embedded monitor is in synchrony 
with that of the ghost monitor. This monitor invari- 
ant is then inserted as an assertion at each security 
relevant method call. The assertions for the remain- 
ing program points could then in principle be com- 
puted using a weakest pre-condition (WP) calculus. 
Unfortunately, there is no guarantee that such an ap- 
proach would be feasible. However, it turns out that 
it is sufficient to perform the WP computations for 
the inlined code snippets and not for the client code. 



under some critical assumptions: 

• The inlined code appears as contiguous subse- 
quences of the entire instruction sequences in the 
inlined methods. 

• Control transfers in and out of these contiguous 
code snippets are allowed only when the monitor 
invariant is guaranteed to hold. 

• The embedded monitor state is represented in 
such a way that a simple syntactic check suffices 
to determine if some non-inlined instruction can 
have an effect on its value. 

The last constraint can be handled, in particular, by 
implementing the embedded monitor state as a static 
member of a final security state class. The important 
consequence is that instructions that do not appear in 
the inlined snippets, and do not include putstatic 
instructions to the security state field, may be an- 
notated with the monitor invariant to obtain a fully 
annotated program. This means, in particular, that a 
simple syntactic check is sufficient to eliminate costly 
WP checks in almost all cases and allows a very open- 
ended treatment of the JVM instruction set. 

The resulting annotations are locally valid in the 
sense that method pre- and post-conditions match, 
and that each program point annotation follows from 
successor point annotations by elementary reasoning. 
This allows to robustly and efficiently generate and 
check assertions using a standard verification condi- 
tion (VC) approach, as indicated in Figure [TJ 

Our approach is general enough to handle a wide 
range of inliners. The developer (who has a better in- 
sight in the application in question) is free to tweak 
the inlining process for his specific application and 
could for instance optimize for speed in certain secu- 
rity relevant call sites, and for code size elsewhere. 

1.1 Related Work 

Our approach adopts the Security-by-Contract (SxC) 
paradigm (cf. [71 [HI [H HOI IH] ) which has been ex- 
plored and developed mainly within the S'^MS project 

m- 

Monitor inlining has been considered by a number 
of authors, cf . [HI [H [H [fl [M] • 
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Figure 1: The architecture of our PCC implementa- 
tion. 



Erhngsson and Schneider |14j represents security 
automata directly as Java code snippets, making the 
resulting code difficult to reason about. The Con- 
Spec contract specification language used here is for 
tractability restricted to API calls and (normal or 
exceptional) returns, and uses an independent ex- 
pression syntax. This corresponds roughly to the 
call/return fragment of PSLang which includes all 
policies expressible using Java stack inspection |15j . 

Edit automata [221 ES] are examples of security 
automata that go beyond pure monitoring, as trun- 
cations of the event stream, to allow also event in- 
sertions, for instance to recover gracefully from pol- 
icy violations. This approach has been fully imple- 
mented for Java by J. Ligatti et al. in the Polymer 
tool [S] which is closely related to Naccio [IS] and 
PoET/PSLang [M]. 

Certified reference monitors has been explored by 
a number of authors, mainly through type systems, 
e.g. in [311 El EH [HI E]: but more recently also 
through model checking and abstract interpretation 
[33l 132] . Directly related to the work reported here 
is the type-based Mobile system due to Hamlen et 
al. [H] . The Mobile system uses a simple library ex- 



tension to Java bytecode to help managing updates 
to the security state. The use of linear types allows 
a type system to localize security-relevant actions to 
objects that have been suitably unpacked, and the 
type system can then use this property to check for 
policy compliance. Mobile enforces per-object poli- 
cies, whereas the policies enforced in our work (as 
in most work on IRM enforcement) are per session. 
Since Mobile leaves security state tests and updates 
as primitives, it is quite likely that Mobile could be 
adapted, at least to some forms of per session policies. 
On the other hand, to handle per-object policies our 
approach would need to be extended to track object 
references. Finally, it is worth noting that Mobile 
relies on a specific inlining strategy, whereas our ap- 
proach, as mentioned in the previous section, is less 
sensitive to this. 

In [33l [32] Sridhar et al. explores the idea of certi- 
fying inlined reference monitors for ActionScript us- 
ing model-checking and abstract interpretations. The 
approach is not tied to a specific inlining strategy and 
is general enough to handle different inlining tech- 
niques including non-trivial optimizations of inlined 
code. Although the certification process is efficient, 
the analysis however, has to be carried out by the 
consumer. 

For background on proof-carrying code we refer to 
[26j . Our approach is based on simple Floyd- like pro- 
gram point annotations in the style of Bannwarth 
and Miiller [3], and method specifications extended 
by pre- and post-conditions in the style of JML [17] . 
Recent work related to proof-carrying code for the 
JVM include [J], all of which has been developed in 
the scope of the Mobius project. 

An alternative to inline reference monitoring and 
proof-carrying code, is to produce binaries that are 
structurally simple enough for the consumer to ana- 
lyze himself. This is currently explored by B. Chen 
et al. in the Native Client project [36] which han- 
dles untrusted x86 native code. This is done through 
a customized compile chain that targets a subset of 
the x86 instruction set, which in effect puts the ap- 
plication in a sandbox. When applicable it has a few 
advantages in terms of runtime overhead, as it elim- 
inates the monitoring altogether, but is constrained 
in terms of application and policy complexity. 
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1.2 Overview of the Paper 

The JVM machine model is presented in Section 2. In 
Section 3 the state assertion language is introduced, 
and in Section 4 we address method and program 
annotations and give the conditions for (local and 
global) validity used in the paper. We briefly de- 
scribe the ConSpec language and (our version of) se- 
curity automaton in Section 5. The example inlining 
algorithm is described briefly is Section 6. Section 
7 introduces the ghost monitor, and Section 8, then, 
presents the main results of the paper, namely the al- 
gorithms for proof generation and proof recognition, 
including soundness proofs. Finally, Section 9 reports 
briefly on our prototype implementation, and we con- 
clude by discussing some open issues and directions 
for future work. 



2 Program Model 

We assume that the reader is familiar with Java byte- 
code syntax and the Java Virtual Machine (JVM). 
Here, we only present components of the JVM, that 
are essential for the definitions in the rest of the text. 
Much of this is standard and can be skipped in a 
first reading. A few simplifications have been made 
in the presentation. In particular we disregard static 
initializers, and to ease notation a little we ignore 
issues concerning overloading. We use c for (fully 
qualified) class names, m for method names, and / 
for field names. Types are either primitive or object 
types, i.e. classes, or arrays. Class declarations in- 
duce a class hierarchy, denoted by <:. If c defines 
m (declares /) explicitly, then c defines (declares) 
cm (c.f). Otherwise, c defines c'.m (declares c'.f) 
if c is the smallest superclass of c' that contains an 
explicit definition (declaration) of cm {c.f). Single 
inheritance ensures that definitions/declarations are 
unique, if they exist. 

We let V range over the set of all values of all types. 
Values of object type are (typed) locations, mapped 
to objects, or arrays, by a heap h. The typing asser- 
tion h \- V : c asserts that v is some location £, and 
that in the typed heap h, i is defined and of type c, 
and similarly for arrays. Typing preserves the sub- 



class relation, in the sense that ii h\- v : c and c <: c' 
then h \- V : c' as well. For objects, it suffices to 
assume that if /i h u : c then the object h{v) deter- 
mines a field h{v).f (method h(v).m) whenever / (m) 
is declared (defined) in c. Static fields are identified 
with field references of the form c.f . To handle those, 
heaps are extended to assignments of values to field 
references. 

A program is a set of classes, and for our purposes 
each class denotes a mapping from method identifiers 
to definitions (/, H) consisting of an instruction array 
/ and an exception handler array H . 

We write c.m[L\ = t to indicate that c(m) = (/, H) 
and that II is defined and equal to the instruction i. 
The exception handler array iJ is a list of of exception 
handlers. An exception handler (&, e, L, c) catches 
exceptions of type c and its subtypes raised by in- 
structions in the range [6, e) and transfers control to 
address L, if it is the first handler in the handler ar- 
ray that catches the exception for the given type and 
instruction. 

A configuration of the JVM is a pair C = {h, R) of 
a heap h and a stack R of activation records. For nor- 
mal execution, the activation record at the top of the 
execution stack has the shape {M,pc, s, I), where M 
is the currently executing method, pc is the program 
counter, s £ Val* is the operand stack, and / is the 
local variable store. Except for API calls (see below) 
the transition relation — >-jvm on JVM configurations 
is standard. A configuration (ft,, (M, pc, s, /) :: R) is 
calling., if A'/[pc] is an invoke instruction, and it is 
returning normally, if M[pc] is a return instruction. 
For exceptional configurations the top frame has the 
form {i) where £ is the location of an exceptional ob- 
ject, i.e. of class Throwable. Such a configuration is 
called exceptional. We say that C is returning excep- 
tionally if C is exceptional, and if C — 5- jvm C implies 
that C" is exceptional as well. I.e. the normal frame 
immediately succeeding the top exceptional frame in 
C is popped in C", if C" is exceptional as well. 

An execution E of a program P is a (possibly infi- 
nite) sequence of JVM configurations CqCi . . . where 
Co is an initial configuration consisting of a single, 
normal activation record with an empty stack, no lo- 
cal variables, M as a reference to the main method 
of P, pc = and for each i > 0, C; — i>jvM Ci+i. 
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We restrict attention to configurations that are type 
safe, in the sense that heap contents match the types 
of corresponding locations, and that arguments and 
return/exceptional values for primitive operations as 
well as method invocations match their prescribed 
types. The Java bytecode verifier serves, among other 
things, to ensure that type safety is preserved under 
machine transitions. 

The only non-standard aspect of — s-jvm is the 
treatment of API methods. We assume a fixed 
API for which we have access only to the signature 
(types), but not the implementation, of its methods. 
We therefore treat API method calls as atomic in- 
structions with a non-deterministic semantics. In this 
sense, we do not practice complete mediation |29] . 
When an API method is called either the pc is in- 
cremented and arguments popped from the operand 
stack and replaced by an arbitrary return value of 
appropriate type, or else an arbitrary exceptional ac- 
tivation record is returned. Similarly, the return con- 
figurations for API method invocations contain an ar- 
bitrary heap, since we do not know how API method 
bodies change heap contents. Our approach hinges 
on our ability to recognize API calls. This property 
is destroyed by the reflect API, which is consequently 
not considered. 



We.fWiKR) 
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||e : c\\{h,R) = 
Figure 2: Semantics of expressions and assertions 



assertion is an assertion that does not reference the 
stack, or any of the local variables. Disjunction 
(V) and implication (=>) are defined as usual. We 
let iF(ao, 01,02) denote the conditional expression 
(oo => ai) A (-lOo => 02) and SELECT(ai, a2, aeZse) 
the generalized conditional expression 

IF(ai_0, 02,0, IF(ai4, 024, . . . , IF(ai^„, 02, „, Oelse) •••))■ 



3 Assertions 

Annotations are given in a language similar to the 
one described by F. Y. Bannwart and P. Miiller in [3]. 
The syntax of assertions a and (partial) expressions 
e are given in the following BNF grammar: 

e ::= v \ e.f \ c.f | s^ | 1^ | e o e | a — e|e | (e, e) | _L 
a ::= tt\ff\ere\aAa\^a\e:c 

where i 6 w. The semantics, as mappings ||e||C 
and \\a\\C is given in Figure [H The operations o 
and r are generic binary operators/relation symbols, 
respectively, with Kleene equality. The expression 
Si refers to the «'th element of the operand stack, 
and li refers to the i'th local variable; the expression 
a — > ei I 62 is a conditional, (61,62) is pairing and tt 
and ff represent true and false respectively; a heap 



4 Extended Method Defini- 
tions 

In this section we extend the method definitions by an 
array of program point assertions and by invariants 
at method entry and (normal or exceptional) return. 

Definition 1 (Extended Method Definition). 
An extended method definition is a tuple 
{I , H, A, pre, post) in which {I,H) is a method 
definition, A is an array of assertions such that 
\I\ = \A\ and pre and post are heap assertions. 
An extended program is a program with extended 
methods. 

For extended programs, the notions of transition 
and execution are not affected by the presence of as- 
sertions. An extended program is valid, if all anno- 
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It 



.H, A, pre, post) 



instanceof c Ai+i[so : c/sq] 

aload n unshift{AL-^-i[ln /sq\) 

astore n {shift(AL+i)) A So = U 

athrow select((so : cAb < L < e){b,e.L'.c}eH 



A locally valid method is one for which each asser- 
tion can be validated by reference to "neighbouring" 
assertions only. 



dup 

getf ield / 
getstatic c.f 
goto L' 
iconst_?i 
if _icmpeq L' 
if eq L' 
invoke cm 
putstatic c.f 
return 
Idc V 
invokestatic 
System, exit tt 



{AL')(b,e,L',c)£H,POSt) 

unshift{AL+i[si/ So]) 
unshift {Al+1 [sq .// So] ) 
unshift{AL+i[c.f / So]) 
Al' 

unshift{AL+i[n/ So]) 
if(so = si, shift^{AL'), shift'-' (Al+i)) " 
if(so 0, shift{AL,), shift{AL+i)) 

Ac 



Definition 3 (Local Validity). An extended method 
AI = {I , H, A, pre, post) is locally valid, if the verifi- 
cation conditions 



1. pre : 

2. Al = 

are valid. 



Ao, and 

wpj^j{L) for all < L < \I\ 



c'£defs{c.m) P^^c'.m 

shift {Al+i)[so/ C.f] 
post 

unshift {Al+i[v/ So]) 



Table 1: Specification of the wpjv/ function 

tations are validated by their corresponding configu- 
rations in any execution starting in a configuration 
satisfying the initial pre-condition. In other words: 

Definition 2 (Extended Program Validity). An ex- 
tended program P is valid if for each maximal execu- 
tion E = CoCi ■■■ Ck of P 



1. 
2. 



IPOS^mai: 



1 1 Co holds, 
a\\Ck holds, and 



3. for each i such that < i < k, if Ci has 
the shape {{M, pc, s,r) :: R,h) and P{M) = 
{I , H, A, pre, post) then \\Apc\\Ci holds 

The WP-calculus used in the proof generation / 
recognition is given in Tabic [T] The definition uses 
the auxiliary functions shift and unshift which incre- 
ments, resp. decrements, each stack index by one 
and defs{c.m) which denotes the set of all classes c' 
such that c <: c' and c' defines m. The account of 
dynamic call resolution in Table [1] is crude, but the 
details are unimportant since, in this paper, pre- and 
post-conditions are always identical and common to 
all methods. 



An extended program is locally valid if all 
its methods are locally valid and the pre-condition of 
the main method holds in an initial configuration. 



We note that local validity implies validity, as ex- 
pected. 

Theorem 1 (Local Validity Implies Validity). For 

any extended program P , if P is locally valid then P 
is valid. 

Proof. Follows by induction on the length of the exe- 
cution. For details wc refer to the Coq formalization 

m. □ 



5 Security Specifications 

We consider security specifications written in a pol- 
icy specification language ConSpec [2], similar to 
PSlang [13], but more constrained, to be amenable 
to analysis. An example specification is given in 
Figure [3] The syntax is intended to be largely self- 
explanatory: The specification in Figure|3]states that 
the program can only send files using the Bluetooth 
Obex protocol upon direct request by the user. No 
exception may arise during evaluation of the user 
query 

A ConSpec specification tells when and with what 
arguments an API method may be invoked. If 
the specification has one or more constraints on a 
method, the method is security relevant. In the 
example there are two security relevant methods, 
GUI. f ileSendQuery and Bluetooth.obexSend. The 
specification expresses constraints in terms before, 
AFTER and EXCEPTIONAL clauscs. Each clause is a 
guarded command where the guards are side-effect 
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SECURITY STATE String lastApproved = ""; 

AFTER file = GUI .f ileSendQueryO 

PERFORM true -> { lastApproved = file; } 

EXCEPTIONAL GUI . f ileSendQueryO 
PERFORM 

BEFORE Bluetooth. obexSend (String file) 
PERFORM file = lastApproved -> { > 

Figure 3: A security specification example written in 
ConSpec. 



Executions produce security relevant actions in the 
expected manner. A calling configuration generates a 
pre-action determined by the called method and the 
current arguments (top n operand stack values for an 
n-ary method) . A returning configuration then gives 
rise to a normal post-action determined by the identi- 
fier of the returning method and the return value (top 
operand stack value). For sake of simplicitly we as- 
sume that all API methods return a value. An excep- 
tionally returning configuration generates an excep- 
tional post-action determined by the method identi- 
fier of the returning method. The security relevant 
actions (the security relevant trace) of an execution 
E is denoted by SRT{E) and formally defined below. 



free and terminating boolean expressions, and the as- 
signment updates the security state. Guards may 
involve constants, method call parameters, object 
fields, and values returned by accessor or test meth- 
ods that arc guaranteed to be side-effect free and ter- 
minating. Guards are evaluated top to bottom in or- 
der to obtain a deterministic semantics. If no clause 
guard holds, the policy is violated. In return clauses 
the guards must be exhaustive. 

5.1 Security Automata 

A ConSpcc contract determine a security automaton 
(Q, S, 5, qo) where Q is a countable (not necessar- 
ily finite) set of states, S is the alphabet of secu- 
rity relevant actions, qq ^ Q is the initial state, and 
(5 : Q X S — > Q is the transition function. We assume 
a special error state -L G Q and view all states in 
Q except _L as accepting. We require that security 
automata arc strict in the sense that (5(_L, a) = _L. 

A security automata is generated by a ConSpec 
contract in a straightforward manner (cf. [T]). The 
alphabet S is partitioned into pre-actions (for calls) 
and (normal or exceptional) post-actions (for nor- 
mal or exceptional returns). Pre-actions have the 
form (cm, v)^, normal post-actions have the form 
(cm, V, r)^ and exceptional post-actions have the 
form (c.m,v)^, where cm is the relevant API- 
method, V is the arguments used when calling the 
method, and r is the returned value. 



Definition 4 (Security Relevant Trace). The secu- 
rity relevant trace, SRT(E), of an execution E is de- 
fined as 

SRT{E) = SRT{E, e) 
SRT{e, e) = e 

({c'.m',^r)''SRT{E,^r :: 7) 

if C = (/i, (cm, pc, V :: s, I) :: R) 
is calling c' .m' 

{c.m,w,r)^SRT{E,i) 

if C = (h, (cm, pc,r :: s,l) :: R) 
is returning and 7 = v :: 7' 



SRT{CE,-f) = < 



{c.m,w)'^SRT{E,j') 

if C ~ {h, (a) :: R) is returning 
exceptionally and 7 = v :: 7' 

_ SRT{E, 7) otherwise 



We generally identify a ConSpec contract with its 
set of security relevant traces, i.e. the language rec- 
ognized by its corresponding security automaton. A 
program is said to adhere to a contract if all its se- 
curity relevant traces are accepted by the contract. 

Definition 5 (Contract Adherence). The program 
P adheres to contract C if for all executions E of P, 
SRT{E) e C. 
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6 Example Inliner 

In this section we give an algorithm for monitor inlin- 
ing (from now on referred to as an inhning algorithm, 
or simply an inliner) in the style of Erlingsson |15j . 
As previously mentioned, the developer is free to de- 
cide what inlining strategy to use, so the algorithm 
presented here serves merely as an example and does 
for instance not include any optimizations. For the 
implementation details and an example, we refer to 
Appendix |^ 

The inliner traverses the instructions and replaces 
each invoke instruction with a block of monitoring 
code. This block of code first stores the method argu- 
ments in local variables for use in post-actions. Then 
the class hierarchy is traversed bottom up for virtual 
call resolution, and when a match is found the rele- 
vant clauses, guards, and updates are enacted. For 
post-actions the main difference is in exception han- 
dling; exceptions are rerouted for clause evaluation, 
and then rethrown. 

We refer to the method resulting from inlining a 
method M (program P) with a contract C as I(M, C) 
(I(P, C)). The main correctness property we are after 
for inlined code is contract compliance: 

Theorem 2 (Inliner Correctness). The inlined pro- 
gram X(P, C) adheres to C. 

Proof. This follows from the fact that we are always 
able to generate a valid adherence proof (theorem ^ 
and that the existence of such adherence proof en- 
sures contact adherence (theorem [3]). (Both state- 
ments are proved in later sections.) □ 



The ghost monitor uses special assignments which 
we refer to as ghost updates: Guarded multi- 
assignment commands used for updating the state of 
the ghost monitor and for storing method call argu- 
ments and dynamic class identities in temporary vari- 
ables. A ghost update has the shape (x^ :— e) where 

is a tuple of ghost variables, special variables used 
only by the ghost monitor, and e is an expression of 
matching type. Typically, e is a conditional of simi- 
lar shape as the policy expressions, and e may men- 
tion security state ghost variables as well as other 
ghost variables holding security relevant call param- 
eters. Given the post-condition A^+i, the weakest 
pre-condition for the ghost instruction (x^' :— e) at 
label L is wpj^.jlL) = ^i+i[e/x^]. 

The ghost updates are embedded right before and 
after each security relevant invoke instruction as well 
as in an exception handler catching any exception 
(Throwable) thrown by the invoke instruction and 
nothing else. Note that the existence of such an ex- 
ception handler is easily checked, and that the code 
delivered by our inliner always has exception handlers 
of this form. The details are presented in Figure H) 
A method M with ghost updates embedded, corre- 
sponding to the security automaton of a contract C 
is denoted by ia{M,C). 

Let I^{M,C) be the result of embedding a ghost 
monitor corresponding to contract C into M. The 
key property of the ghost monitor is that the trace of 
ghost monitor states in an execution E, is the same 
as the states visited by the security automaton, given 
SRT{E) as input. This is easily be shown by an 
induction over the length of E. 



7 The Ghost Monitor 

The purpose of the ghost monitor is to keep track 
of what the embedded monitor state should be at 
key points during method execution. This provides a 
useful reference for verification. Moreover, since the 
ghost monitor assigns only to special ghost variables 
that are invisible to the client program, and since it 
is incapable of blocking, it does not in fact have any 
observable effect on the client program. 



Lemma 1. Let E = C'o . . . Ck be an execution of 
X^{P,C) and msf denote the ghost monitor state in 
configuration d. If for all < i < k, msf ^ _L, then 
SRT(E) e C. 



Proof. Follows by induction on the length of the exe- 
cution. For details we refer to the Coq formalization 
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8 Contract Adherence Proofs 



L: ((ts, argsl, . . . , argsfj (.s„, . . . , sq)) 
(ms^ :— P : (5(ms^, {c'^.m, args^)^) 

P : ^ (5(ms^, (c^.m, args^Y) 

invokevirtual cm 

(ms^ :— P : — !> (5(ms^, (c'^.m, args^ , sq)^) 
P : ^ (5(ms^, {c^.m, args^ , sq)^) 



LHStart- (ms^' := P : c'^ ^ S{ms^, {c'^.m, args^)^) 
P : ^ (5(msS, (c^m, args^)^) 

Figure 4: Ghost updates induced by security automa- 
ton (Q, E, i5, (7o) for an invokation of cm, where 
is the target object, args^ represents the arguments 
and <: ... <: denote ah API-classes defining or 
overriding m. 



The key idea of a contract adherence proof is to 
show that the embedded monitor state ms of the pro- 
gram I^{P,C) and the ghost monitor state ms^ are 
in agreement at certain program points. These points 
certainly need to include all potentially security rel- 
evant call and return sites. But, since we aim for a 
procedural analysis, and to cater for virtual call res- 
olution actually all call and return sites are included. 
In fact, this is all that is needed, and hence: 

Definition 6 (Adherence Proof). An adherence 
proof for program P and contract C assigns to each 
method M ~ (lyH) in X^{P,C) an assertion ar- 
ray A such that the extended method (/, H, A, ms = 
ms^,ms = ms^) is locally valid. 

Such an account has two main benefits which are 
heavily exploited below: 

• It leaves the choice of a particular proof genera- 
tion strategy open. 

• It opens for a lightweight approach to on-device 
proof checking, by performing the local valid- 
ity check on a program with a locally produced 
ghost monitor. 

Theorem 3 (Adherence Proof Soundness). If an ad- 
herence proof exists for a program P and contract C, 
then P adheres to C. 

Proof. Assume 11 is an adherence proof for a program 
P and a contract C. By theorem [T] we know that 
the corresponding extended program for I^(P, C) is 
globally valid. This implies that ms = ms^ at each 
configuration that is calling (or returning from) a se- 
curity relevant configuration. Furthermore, since the 
_L value is an artifical "error" value of the security 
automaton with no Java counterpart, we know that 
if ms = ms^, then ms^ 7^ ±. Thus, by lemma [TJ 
SRT{E) e C and therefore P adheres to C. □ 

8.1 Example Proof Generation 

The process of generating contract adherence proofs 
is closely related to the process of embedding the ref- 
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erence monitor, thus the inhning and proof genera- 
tion is preferrably done by the same agent. This sec- 
tion describes how proofs may be generated for code 
produced by the example inhner presented in Section 

m 

The monitor invariant, ms = ms^* is set as each 
methods pre- and post-condition. The assertion for 
each specific instruction is generated differently, ac- 
cording to whether the instruction appears as part 
of an inlined block or not. Instructions inside the 
inlined block affect the processing of the embedded 
state, method call arguments etc. For this reason 
these instructions need detailed analysis using the wp 
function. Instructions outside the inlined blocks, on 
the other hand, allow a more robust treatment, as 
they are only required to preserve the monitor in- 
variant which they do (see fact [T] in Appendix IX)) . 
The critical property of the annotation function is 
the following: 

Lemma 2. Given a method M = (I,H) ofIs{P,C) 
and a set IL labelling the inlined instructions in I , an 
array A of assertions can be computed such that the 
extended method {I, H, A,ms = ms^,ms = ms^) is 
locally valid. 

Proof. A general construction is illustrated in Ap- 
pendix |B] □ 

The array is constructed by annotating the return 
instructions with the post-condition, and then in a 
breadth first manner, annotate the preceeding in- 
structions using the wp function in case of inlined 
instructions and by using the monitor invariant in 
other cases. 

Theorem 4 (Proof Generation). For each program 
P and contract C there is an algorithm, polynomial 
in \P\ + \C\, which produces an adherence proof of 
J(P,C). 

Proof. The algorithm described above treats each 
method in isolation. The breadth first traversal of 
the instructions takes time linearly proportional to 
the size of the instruction array plus the number of 
ghost updates. The resulting adherence proof is cor- 
rect by construction. □ 



As an example Figure [S] illustrates a generated 
proof for a part of a program which has been inlined 
to comply with the policy in Figure [5] 

SCOPE Session 

SECURITY STATE boolean haveRead = false; 

BEFORE j avax . microedition . rms . RecordStore 
. openRecordStore (string name, 
boolean createlf Necessary) 
PERFORM 

true -> { haveRead = true ; } 

BEFORE j avax .microedition. io . Cormector 

. openDataOutputStresun (string url) 
PERFORM 

haveRead == false -> { } 

Figure 5: A ConSpec specification which disallows 
the program from sending data over the network after 
accessing phone memory. 

8.2 Proof Recognition 

Checking the validity of contract adherence proofs 
involves verifying local validity, which in general is 
undecidable. However, the problem is much simpli- 
fied in our setup, since proofs apply to programs that 
have already been inlined. Validity checking may still 
be hard or impossible, however, due to the use of 
primitive data types with difficult equational theo- 
ries. For this reason the theorem below is restricted 
to contracts over freely generated theories. 

Theorem 5 (Efficient Recognition) . The class of ad- 
herence proofs generated from programs inlined with 
contracts over a freely generated theory is recognizable 
in polynomial time. 

Proof. To verify the validity of a given adherence 
proof we look at the requirements of definition [5] 
Verifying that the pre- and post-conditions equal the 
monitor invariant is a simple syntactic check and can 
be done in time linearly proportional to the number 
of methods in P. 
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40:{*} 
aload_l 
' 41 : {if(0 / SS.haveRead, tt, 

w{haveRead^ = if, _L = SS.haveRead))} 
astore_3 
42: {if(0 / SS.haveRead, tt, 

lF{haveRead^ = ff, *, ± = SS.haveRead))} 
getstatic SS.haveRead 
45:{if(0 / So, tt, 

w{haveRead^ = jff, *, _L = SS.haveRead))} 
iconst_0 
46:{if(so / si, tt, 

w{haveRead^ = ,|f, *, _L = SS.haveRead))} 
if_icmpne 52 
^9:{l¥{haveRead''' = jff, *, _L = SS.haveRead)} 

goto 56 
52:{tt} 

iconstjnl 
55:{tt} 

invokestatic System. exit 
b&:{lF{haveRead'' = if, *, ± = SS.haveRead)} 
aload_3 

{lF{haveRead''' = ,|f, *, ± = SS.haveRead)} 
{haveRead^ := haveRead^ ~ff^ haveRead^ 
71:{*} 

invokestatic 

Connector . openDataOutputStream 

74: {1'} 

astore_2 



Figure 6: Generated assertions for inlining of 
Connector . openDataOutputStream where de- 
notes the monitor invariant. 

For the requirement of local validity, it is sufficient 
to check that the verification conditions 1 and 2 from 
definition |3] can be rewritten to tt in time polynomial 
in the size of the instruction array. The interesting 
verification conditions arc those of the form Al ^ 
wpj^j{L) where L is the label of the first instruction 
in an inlined block. Al is, in this case, of the form 
ms = ms^ A Oq = ao = So A . . . A a,^ = a„i = s,„ and 
wpj^i^L) is of the form 

SELECT((t : c" A t9 : c", . . . , t : A : c^). 



(SELECT((c".mGj A c^.m^^,. . . ,c".mc, A c".m^J, 
(c".m/j (ms, a) ~ c" .mP^^ (ms^ , ), . . . , 
c".mj. (ms,a) = c".my. (ms^, a^*)), tt), 

SELECT((c^mGj A c^.-mpQ^ , c^.tug^ A c^m^^), 
c^.mf^ (ms, a) = .mP^^ (ms^*, a^ ), . . . , 
c^.mf. (ms, a) = c^.rrij, (ms^ , a^)),tt)), 
ms — ms^ ) 

The verification condition can then be rewritten 
and simplified by iterated applications of the rule 
X = y ^ (j) — ^ 4'[z/x][z/y] where x and y are in- 
stantiated with real variables and ghost counterparts 
respectively and where z does not occur in (j). These 
rewrites can be performed in time proportional to 
the length of the formula and does not increase the 
size of the expression since x, y and z are atomic. 
The result can then be rewritten to tt using the rules 
{ip ^ (p) A ^ (j)) — > (j) and (j) = (p — ^ in time 
polynomial in the size of the formula. 

All other verification conditions [prej^j => Aq, 
Al wpj^f{L) for all labels L except those of the 
first instructions in an inlined block are trivial as their 
antecedents and succeedents are identical. □ 

9 Implementation and Evalua- 
tion 

A full implementation of the framework, includ- 
ing a Java SE proof generator, a Java ME 
client, instructions and examples is available at 
Iwww. CSC . kth. se/~lajidreas/irm_pcc Both the on- 
and the off-device software utilize a parser generated 
by CUP / JFlex [HET] and the ASM library gT] for 
handling class files. Table [2] summarizes overhead for 
inlining, proof generation and load-time proof recog- 
nition on two example applications and policies: 

• MobileJam: A GPS based traffic jam reporter 
which utilizes the Yahoo! Maps API. 

Policy: Only connect to 

http : / /local . yELhooapis . com 

• Snake: A classic game of snake in which the 
player may submit current score to a server. 
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MobileJam Snake 



Security Relevant Invokes 


4 




2 




Original Size 


428.0 


kb 


43.7 


kb 


Size increase for IRM 


4.8 


kb 


1.1 


kb 


Size increase for Proofs 


20.6 


kb 


2.6 


kb 


Inlining 


10.1 


s 


8.6 


s 


Proof Generation 


4.7 


s 


0.8 


s 


Proof Recognition 


98 


ms 


117 


ms 



Table 2: Benchmarks for the two case studies. 



Policy: Do not send data over network after 
reading from phone memory. 

Inlining and proof generation was performed on an 
Intel Core 2 CPU at 1.83 GHz with 2 Gb memory and 
proof recognition was performed on a Sony-Ericsson 
W810i. The implementation is to be considered a 
prototype, and very few optimizations in terms of 
e.g. proof size have been implemented. 

10 Conclusions 

We have demonstrated the feasibility of a proof- 
carrying approach to certified monitor inlining at the 
level of practical Java bytecode, including exceptions 
and inheritance. This answers partially a question 
raised by K. W. Hamlen et al. [15] . 

Wc have proved correctness of our approach in 
the sense of soundness: Contract adherence proofs 
are sufficient to ensure compliance. This soundness 
proof has been formalized in Coq. We also ob- 
tain partial completeness results, namely that proofs 
for inlined programs can always be generated, and 
such proofs are guaranteed to be recognized at pro- 
gram loading time, at least when contracts do not use 
equational tests that are too difficult. Other prop- 
erties are also interesting such as transparency [H], 
roughly, that all adherent behaviour is preserved by 
the inliner. This type of property is, however, more 
relevant for the specific inliner, and not so much for 
the certification mechanism, and consequently not 
addressed here (but see e.g. [531 IMl US for results 
in this direction). 

The approach is efficient: Proofs are small and 



recognised easily, by a simple proof checker. An 
interesting feature of our approach is that detailed 
modelling of bytecode instructions is needed only for 
instructions appearing in the inlined code snippets. 
For other instructions a simple conditional invari- 
ance property on static fields of final objects suf- 
fices. This means, in particular, that our approach 
adapts to new versions of the Java virtual machine 
very easily, needing only a check that the static field 
invariance is maintained. Worth pointing out also is 
that the enforcement architecture can be realized in a 
way which is backwards compatible, in the sense that 
PCC-aware client programs can be executed without 
modification in a PCC-unaware host environment. 

It is possible to extend our framework to multi- 
threading by protecting security relevant updates 
with locks, either locking the entire inlined block or 
releasing the lock during the security relevant call it- 
self for increased parallellism. For proof generation 
the main upshot is that assertions must be stable 
under interference by other threads. Briefly, this re- 
quires the ability to protect fields, such as those in the 
security state class, with locks by only allowing up- 
dates of these fields when the lock has been acquired. 
The validity of an assertion may then only depend 
on fields protected by locks that has been acquired 
at that point in the code. This work is currently in 
progress. 
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A Implementation of the Ex- 
ample Inliner 

Our inliner lets the state of the embedded security 
monitor be represented by a static field ms of a fi- 
nal security state class, named to avoid clashes with 
classes in the target program. This choice of repre- 
sentation relies on the following fact of JVM execu- 
tion and allows for our open-ended treatment of large 
parts of the instruction set. 

Fact 1. Suppose c is final and f is static. If 
C = {h,{M,pc, s,r) :: R) -^jvm C and AI[pc] ^ 
putstatic c./, then \\c.f\\C = \\c.f\\C" . 

In other words, the only instruction which can af- 
fect the value stored in a static field / of a final class c 
is an explicit assignment to c.f. In particular, the as- 
sumption ensures that instructions originating from 
the target program are unable to affect the embedded 
monitor state. 

For simplicity we assume (without loss of general- 
ity) that ConSpec policies initialize the security state 
variables to the default Java values. 

Each invokevirtual cm instruction is replaced 
by a block of inlincd code that evaluates which con- 
crete method is being invoked, then checks and up- 
dates the security state accordingly. We assume for 
simplicity that no instructions in a block of inlined 
code other than athrow will raise exceptions. The 
code is easily adapted at the cost of some additional 
complexity to take runtime exceptions violating this 
assumption into account. 

Figure [7] shows a schematic policy for a method 
TO : int — >■ int defined in class a c and overridden in a 
subclass d. The policy has event clauses for before, 
AFTER and EXCEPTIONAL cascs for each definition of 
TO, each with two guards and two statement lists. 

Figure [8] gives the inlining details for the policy 
schema in FigureO In the figure, each [EVALUATE g] 
section transforms a configuration {h,{M,pc,s,r) :: 
R) to (/i, {M,pc',v :: s,t) :: R) where u is or 1 if 
the guard g is false or true respectively. An [EXECUTE 
stmts] transforms the configuration {h, (M,pc, s, r) :: 
R) to (ft,[|siTOis](ms)/ms], (M, pc',s,r) :: R). 

The remaining invoke instructions (invokestatic. 



SCOPE Session 

SECURITY STATE int ms = 0; 



BEFORE 


c . 


mCint 


a) 


PERFORM 




-> 


{cb^j} 
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{cb,^} 
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-> 


{cas J } 
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EXCEPTIONAL 
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mCint 
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PERFORM 




-> 


{de^j} 
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-> 


{de„} 



Figure 7: Schematic ConSpec policy 



invokeinterf ace and invokespecial) can be han- 
dled similarly. 
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ifeq daGrd2 








FFXFCUTF Ha 1 




[EXECUTE cbsjj 




goto AEnd 




goto BEnd 


daGrd2 : 


[EVALUATE dag^] 


cbGrd2 : 






ifeq daFail 




ifeq CbFail 




[EXECUTE das 2 J 




[EXECUTE cbsaJ 




goto AEnd 




goto BEnd 


daFail : 


iconst_l 


cbFail: 


iconst_l 




inv_static Sys.exit 




inv_static Sys.exit 


caChk: 


aload rt 


BEnd: 


invokevirtual cm 




instanceof c 




goto hdlEnd 




ifeq AEnd 


hdlStrt : 


aload rt 


caGrdl : 


[EVALUATE CBg^] 




instanceof d 




ifeq caGrd2 




ifeq ceChk 




[EXECUTE casiJ 


deGrdl : 


[EVALUATE deg^] 




goto AEnd 




ifeq deGrd2 


caGrd2 : 


[EVALUATE cag^] 




[EXECUTE de^iJ 




ifeq caFail 




goto EEnd 




[EXECUTE cas^J 


deGrd2 : 


[EVALUATE deg^] 




goto AEnd 




ifeq deFail 


caFail : 


iconst_l 




[EXECUTE de^aJ 




inv_static Sys.exit 




goto EEnd 


AEnd: 





Figure 8: Schematic inlining of policy in Figure [7] 
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B Proof of Lemma [2] 

Figure [To] shows the construetion for a cah of a 
method m : int — > int in class c, under the 
schematic contract shown in Figure [HI We assume 
that an exception thrown by the invoked method is 
matched by an exception handler table entry on the 
form (30,32,34,071?/). For brevity we let abef, craft 
and aexc denote the appropriate substitution for the 
effect of updating ms according to the before, after 
and exceptional clause of cm respectively. For in- 
stance, if bef^ denotes ms = ms * x; ms = ms - 5, 
then (Jbef is [(ms • x) — 5/ms]. 

SCOPE Session 

SECURITY STATE DECLARATION 

BEFORE c.mCint a) PERFORM befg -> {befs> 

AFTER r = c.m(int a) PERFORM aftg -> {afts> 
EXCEPTIONAL c.m(int a) PERFORM exCg -> {exCs> 

Figure 9: Schema contract for the proof of Lemma [2l 



34: 
38: 



I ms^ 



17. 



ms — ms^ 

NDN-INLIMED INSTRUCTION 
// INLINED CODE START 
ms — ms^ 
ASTORE a 
ASTORE t 
ALOAD t 
ALOAD a 
// BEFORE 
IF(t : c, A28, A30) 
ALOAD t 
INSTANCEOF c 
IFEQ 30 

IF(bef g , if(.si : c,lF(beig,msiTbef{a,) 
ms — ms^ ) A a — sq A t — si, tt) 
[EVALUATE befg] 
IFEQ 29 
[PERFORM befs] 
GOTO 30 
tt 

ICONST.l 

INVOKESTATIC System. exit 

if(si : c, IF(bef g, ms — ms^ a^ef {sq), ms — _L), ms — ms^) A 

a — So A t — si 
((tf.af) := (si.so)) 

(ms" := : c -> S{ms^ , {cm, a^)'') \ ms") 
ms — ms" A a — A t — 
INVOKEVIRTUAL c.mCint) : Int 
ms = ms" A a = a" A t = t" 
(r" := So) 

(ms" :— t" : c — > (5(ms" , (cm, a" , r" )' 

^43[r/so] 
ASTORE r 
ALOAD r 

A43 

GOTO 43 

// EXCEPTIONAL 

ms = ms" A a = a" A t = t" 
(ms" := t" : c ^ <5(ms", (cm, a")*) | 
IF(t : c, A40, A42) 
ALOAD t 
INSTANCEOF c 
IFEQ 42 

IF(exCg , msCTe^c (fi) — ms", A41) 
[EVALUATE exc,] 
IFEQ 41 
[PERFORM exca] 
GOTO 42 
tt 

ICONST.l 

INVOKESTATIC System. exit 
ms — ms" 
ATHRDW 
// AFTER 
iF(t : c, A44, Aie) 
ALOAD t 
INSTANCEOF c 
IFEQ 46 

IF(aftg, ms(Taft(T, a) — ms", tt) 
[EVALUATE aftg] 
IFEQ 45 
[PERFORM aftg] 
GOTO 46 
tt 

ICONST.l 

INVOKESTATIC System. exit 
// INLINING END 
ms — ms" 

NON-INLINED INSTRUCTION 



Figure 10: Schematic annotation for contract dis- 
played Figure [9] 



